在前幾天的文章中，我們探討了需求分析和Wirefrime的設計。今天，將介紹這次專案的技術選型與架構設計。由於專案是從無開始，可以選自己想要熟悉的技術。我覺得也是一個優點。畢竟寫程式的人其實都會很喜歡自己創造東西的感覺吧。

下面表格為這次選用的技術，後面詳細說一下選擇的原因。

技術選擇考量

通常接案的話畢竟和上班不太一樣，也不一定會有後續的維護。雖然自己開發的話，維護應該還是會找你，只要收費不要太離譜又是認識的人的話。

但我覺得最難的其實是自己的時間分配，下班假日大部分就只想休息。我覺得簡單快速實作出來也是很重要的一件事！！那這樣就選擇自己熟悉的技術會比較好。

前端

React Native

其實我沒有寫過 RN，但想說 React 和 React native 差不多吧。至少學習成本不高吧，多學也沒差就接下來了。事實上呢？我覺得其實還是有落差，而且APP會有很多奇怪的事很麻煩...。部署也沒有網頁方便，其實很多事情現在網頁都做得到了。如果要開始一個APP專案之前，可能可以先想想看是否非要寫APP不可？怎麼才一開始就像在勸退呢（笑

選擇 React Native理由：

• 跨平台開發：一次開發，兩個平台同時支援，減少重複工作量。
• 豐富的生態系統：React Native 擁有活躍的社群和豐富的第三方套件，能夠快速實現掃描、照片上傳等功能。
• React 使用者：對於前端 React 使用者來說，上手比較快。RN 讓你可以用類似 React 的寫法寫APP，讓你可以快速入門APP

Redux Toolkit

狀態管理 Redux 應該是寫 React 的專案都會使用的，主要是在所有頁面都可以共享狀態，方便做狀態管理。不過傳統的 Redux Saga 有點太麻煩，所以選用 redux toolkit，比較快速方便，可以減少寫很多 code。

選擇 Redux Toolkit理由：

• 簡化 Redux 開發流程：內建的 createSlice 和 createAsyncThunk 等功能，讓開發者能夠更快地定義 reducer 和處理異步操作。
• 狀態管理集中化：透過 Redux，所有的數據和狀態都集中管理，這樣能夠確保在多個頁面之間共享資料，例如報告列表、表單數據等。

後端

其實我後端不太熟悉，之前專案有做過使用 loopback4 作為後端框架搭建網站。但 loopback最後好像沒有比較流行也大改了，當初寫的時候還沒有TS。既然都要花時間成本學習的話，那選個最近比較流行的好了，所以我選擇了 Nest.js。雖然

Nest.js

Nest.js 是基於 TypeScript 的後端框架，Nest.js 學習成本會比較偏高，但我評估後覺得專案應該只是CRUD比較多，比較不會有複雜的計算。當作入門的學習練習好像不錯。

選擇 Nest.js的理由：

• 模組化架構：Nest.js 允許我們使用模組化結構來組織程式碼，使應用更容易維護和擴展。
• 強大的 TypeScript 支援：Nest.js 的全 TypeScript 支援讓我們能夠在前後端共享型別定義，提高開發效率並減少錯誤。
• 完整的框架：NestJS 採用模組化的架構，將應用程式分解成多個獨立模組，便於管理和擴展。每個模組都包含控制器、服務和提供者，這樣可以保持代碼結構的清晰和有條理。
• 易於整合：Nest.js 很容易與 MongoDB、AWS 等技術進行整合，無論是資料庫管理還是文件上傳都能簡單對接。

MongoDB

其實選擇 MongoDB 就沒什麼特別的理由了，因為公司是用 MongoDB，想說習慣就好。不過 MongoDB 使用和學習成本都不算太高，在只是一開始的小專案其實我覺得資料庫的選用到還好，還不用考慮太多後面的事，選擇順手習慣的就好了。畢竟，也不知道有沒有後面。

OCR 技術

先前接案的網站有做過實名認證的系統，最一開始的時候因為我技術不夠，當時也沒有這麼多 OCR 服務也許有，但我可能不熟不知道。那時候我們串接了德國一個實名認證系統 -Passbase，它可以辨識很多國家的身分證駕照健保卡之類的，台灣的也可以，很厲害！

題外話，他的中文化服務是我們協助的。

不過前陣子他們停止服務了，所以我們就需要自己做一個實名認證系統。雖然是這樣說啦，但其實就只有錄影和上傳證件辨識文字而已。因為那時公司的專案也有在做辨識醫事人員小卡，使用 GCP的 google cloud vision，所以就選用了這個實作。

這次是因為客戶選用AWS，但我想應該都差不多吧。

AWS Textract：

• 文字與結構化資料提取：AWS Textract 不僅能進行傳統的 OCR，還能識別表單和表格中的結構化資料，保持原有的版面格式。這對於需要自動提取文檔中的數據、表格、或表單的應用非常有幫助。
• 手寫字識別：Textract 還具備手寫文字的識別功能，這在需要處理各種票據、表單等手寫資料時非常實用。
• 整合：Textract 與其他 AWS 服務（如 S3、Lambda、Comprehend 等）無縫整合，能構建自動化的工作流程和數據處理流程。
• 定價：AWS Textract 採用按需付費模式，根據處理的頁數計費，因此對於不需要大規模處理的應用來說，成本是靈活可控的。

詳細資訊： AWS Textract

Google Cloud Vision AI：

• 多功能識別：Google Cloud Vision AI 除了 OCR 之外，還能識別圖像中的物體、場景、標誌、地標等，適合需要更全面影像分析的應用。這讓它在處理圖像時不僅僅是文字識別，還能實現圖像內容的全面分析。
• 準確性與語言支援：Google Cloud Vision 的 OCR 功能對於多語言的支援相當全面，能處理全球多種語言的文字，這對於國際化應用場景非常有優勢。
• 定價：Google Cloud Vision 也採取按次數付費模式，基於 API 請求次數來收費，對於需要大量處理的企業來說可以根據需求進行調整。

詳細資訊：Google Cloud Vision AI

相比之下，Google Cloud Vision 更加全能，適合需要圖像識別的應用，但 AWS Textract 在表單處理上更專業。

部署相關

圖片儲存與部署

AWS S3

我們使用 AWS S3 作為圖片和文件的儲存庫。S3 是一個高度可擴展、可靠的雲端存儲解決方案，適合存儲事故現場的圖片和其他相關文件。

• 高擴展性與可靠性：S3 提供幾乎無限的儲存空間，並保證資料的高可用性，非常適合長期存儲大量圖片和文件。
• 易於整合：S3 能夠無縫整合到 Nest.js 和 React Native 應用中，通過簡單的 API 調用即可實現文件上傳與管理。

AWS EC2

後端伺服器放的地方，我們選擇了 AWS EC2 作為應用的運行環境。EC2相對穩定，但收費也比較高一些。畢竟出錢的不是我，如果只是測試的話，我自己會選擇 Digitalocean 買個便宜的虛擬機來放，比較便宜。

Docker

將應用程式打包成 docker image，以保證開發環境和生產環境的一致性，並簡化部署流程。

Docker 也需要學習滿多東西的，但沒關係，我們這邊就教大家會用得到的部分就好了。比較偏向簡易部署的部分。

CI/CD

為了提高開發效率和持續交付能力，我滿建議要做 CI/CD（持續整合/持續部署） 流程。這樣能夠自動化測試與部署，確保每次更新代碼都能即時部署並進行測試。但通常接案開發應該只會做到更新部署自動化而已，測試的話我覺得甚至連公司的產品也很少會有完整的。

結語

我打完上面一篇，深深的嘆了一口氣，覺得要獨立完成一個產品要會的東西好多。不知道如果只是想入門的人會不會看到要會一大堆後覺得還是算了。

但我想和大家說的是，雖然東西技術很多，但你不一定也沒必要全部都會。只需要你會用的部分就可以完成這個需求了。

然後現在有 ChatGPT，不會的話可以問他。他會和你說答案的。沒問題的！我自己也不是全部都會，很多時候也都是遇到了再說。

工商時間

又到了我們最後的工商時間啦～～～。Tom有在經營 Pocast，目前比較偏向職場類的閒聊，未來Podcast預計更新與程式軟體開發相關的主題。有興趣的朋友follow一下。

可以透過以下平台收聽： Apple podcast Spotify KKBOX
Linking Tree